home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 2168 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  8.0 KB
  1. Path: news.cc.uic.edu!sunphy1!olczyk
  2. From: olczyk@sunphy1 (Thadeus Olczyk)
  3. Newsgroups: comp.lang.c++,comp.lang.pascal.delphi.misc
  4. Subject: Re: C++ with Zapp vs. Delphi
  5. Followup-To: comp.lang.c++,comp.lang.pascal.delphi.misc
  6. Date: 16 Jan 1996 07:09:46 GMT
  7. Organization: University of Illinois at Chicago
  8. Message-ID: <4dfivq$34fs@tigger.cc.uic.edu>
  9. References: <4coar6$d4n@sun4.bham.ac.uk> <4coip7$69s@news1.usa.pipeline.com> <fRA+w0JfFG5X089yn@oslonett.no> <4dcc4d$6anc@tigger.cc.uic.edu> <4ddke3$5lf@fountain.mindlink.net>
  10. NNTP-Posting-Host: sunphy1.phy.uic.edu
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. Brent Bysouth (brent_bysouth@mindlink.bc.ca) wrote:
  14. : You don't seem to understand the significance of RTTI in Delphi.  You
  15. As far as I understand RTTI in Delphi,  it is a slightly weaker version
  16. of the C++ version. If so then it considered bad practice -- violating 
  17. the open/close principle. If not then Borland had better clean up their 
  18. documentation because I have never seen any mention of it. 
  19.  
  20. : can execute methods and set/get properties by name lookup -- ie.
  21. : dynamic method resolution similar to what's in ObjectiveC & Smalltalk.
  22. : Delphi's VCL makes extensive use of this when components are streamed
  23. At first I thought you might have a point, but if you mean what goes on
  24. in TPersistent then it's complexity  (which is imposed by the nature of Delphi)
  25. proves my point. Can you give an example?
  26. If it's what I think you are saying, then it is not similar to ObjC or 
  27. SmallTalk. It's a lot more complicated and error prone.
  28.  
  29. : in from form files.  Also, through the use of virtual constructors and
  30. : class references (ie. metaclasses), you can write generic code that
  31. : constructs objects of unknown subtypes.  I've personally used these
  32. : things to implement a pseudo-late binding class "factory" that you can
  33. : load from DLLs.
  34. Again I would like to see an example. Especially since you don't use classes
  35. in the iterface to a Dll.
  36.  
  37. : Given many of Delphi's RAD competitors, I can see why RAD has a bad
  38. : name.  Delphi is popular because it is a 'second-generation' RAD tool,
  39. : and eliminates many of the problems of first generation RAD tools.
  40. Strange considering the prime complaints about RAD are:
  41. 1) Analysis and design are given short shrift, leading to bad architecture
  42.    and major difficulty when complexity rises. 
  43. 2) Pressure to accept a prototype for final product. This is going to
  44.    be especially nasty in Win95 and NT.
  45.  
  46. : Yes, I agree that cutting & pasting code brings on maintenance
  47. : nightmare.  I'm less sure that a lack of MI does though, as would many
  48. If the lack of MI causes cutting and pasting then a lack of MI does bring
  49. maintenance problems. That's my arguement.
  50.  
  51. : others.  MI vs. SI is an age old argument, and you're not going to get
  52. : a concensus on it anytime soon.  If you really want a discussion on
  53. : it, start a thread in comp.object!
  54. MI vs SI is not an old arguement. Statically typed MI (Eiffel,C++) vs.
  55. dynamically typed SI (ObjC, Smalltalk) is an old arguement. I have never 
  56. seen a thread on comp.object which argued that statically typed SI beats 
  57. statically typed SI(Delphi).
  58.  
  59. Of course if your first point is correct...
  60.  
  61. : >: >Maybe C vs. Pascal , but C++ is OO and Object Pascal is a fraud perpetuated by 
  62. : >: >Borland on the world.
  63.  
  64. : Would you care to elaborate on this one?  If you're attempting to say
  65. : that C++ is more OO than Object Pascal, could you back this up?
  66. Same as above.
  67. I would point out that just because a language has all the OO features
  68. described in books, that does not make it OO. If I have all the parts
  69. for a car, but they don't fit together (different brands of car)
  70. well enough for the "car" to run,
  71. I don't really have a car do I?  The same with OO languages. The features 
  72. have to work together.
  73.  
  74. : >If MI is not so great why does Borland simulate it in the VCL? Did you notice
  75. : >that I pointed this out? 
  76.  
  77. : I think all of us noticed you saying that. Please support it though --
  78. : give examples of where Borland simulated MI in the VCL.  However,
  79. : don't confuse MI with delegation (which at least Object Pascal and
  80. : Objective C support and encourage) and association (do any mainstream
  81. : languages support this as a language feature?).  
  82. It has been a while (two months since I looked at the source), but look
  83. at the FList in TStrings or FDataLink in the DB classes. I will have to 
  84. take a closer look ( I can't right now ) before fully committing myself.
  85. A bit of a trade off here. My example for your example no?
  86.  
  87. : Are you commenting on unit level access to protected and private
  88. : variables (ever heard of friends in C++?) ? Please clarify...
  89. (Sorry bad editing on my part.)
  90. Take an object Controler which contains a TList. In the TList I want to
  91. store classes MyA, MyB,MyC ... which are A,B,C ... with the extra method 
  92. foo. If you have multiple inheritence make an ABC with foo as the only method
  93. and store the ABC, derive MyA from A and the ABC. In Delphi you have to--
  94. 1) Store each class and use RTTI -- violation of the open/closed principle.
  95. 2) Store a function pointer to foo ( fake multiple inheritence).
  96.  
  97. Of course if you can use delegation, that's another thing. But then that seems
  98. to be the meat of the whole arguement.
  99.  
  100. : >Add to the other weaknesses of Delphi the fact that you can instantiate 
  101. : >abstract classes. How good is a language which allows you to make a
  102. : >contract and then break it.
  103.  
  104. : I've often wondered myself why you can instantiate abstract classes.
  105. : However, if you're coming from a C++ background, I think it's a bit
  106. : hypocritical to make the second statement that you did.  Why not talk
  107. : about C++'s problems wrt its VMT? Ie.
  108.  
  109. : - C++ objects are not binary compatible across compiler
  110. : implementations
  111. A bit hypocritical to bring up this particular problem considering
  112. that Delphi can't possibly have it, there being only one compiler 
  113. implementation (which is not really true as TP object files are not
  114. compatible with dcu's). I've rarely seen two different compilers which
  115. were compatible with each other.
  116.  
  117.  
  118. : - changes in C++ objects that affect the VMT mean that code accessing
  119. : that object must be recompiled (can this be classified as a
  120. : "maintenance nightmare"?).  This is probably C++ worst problem -- it
  121. : gets to the point where DLLs compiled from C are more reliable and
  122. : reusable than those from C++.
  123. This is a choice of compiler writers. 
  124. If people really want this fixed, they will fix it.
  125. I personally prefer it this way, it produces faster code and makes me work 
  126. hard to minimise my dependencies.
  127.  
  128. : BTW, Delphi has a VMT but also supports a dynamic method table that
  129. : gets around this problem (ie: methods declared with the dynamic and
  130. : message directives).
  131. At the cost of speed. See above.
  132.  
  133. : I classify properties as a nice-to-have (but non-essential) feature.
  134. : I classify MI as the same -- Object Pascal & Smalltalk surely seem to
  135. : get by alright without them.  (Or at least you haven't proven
  136. : otherwise).
  137.  
  138. : And yes, if you want container classes, you can construct them using
  139. : Delphi's RTTI and class objects.  They wouldn't be a compiler-known
  140. : entity (ie. they wouldn't have full static typechecking), but you
  141. : certainly can do them.
  142. Ah, but such lasses are already a part of the C++ library (STL), and
  143. though most implementations don't conform to the standard ( another
  144. plus, ask any OWL programmer ) every PC compiler comes with such. you
  145. can also purchase others or get the STL by ftp. 
  146.  
  147. : ---
  148.  
  149. : Alas, after having said all this, I'm not sure that you're interested
  150. : more in discussion or in flaming.  Your response to Rune seems to
  151. : indicate the latter.
  152. -----
  153. Nope.
  154. Rune didn't seem interested in reading much of my post.He just
  155. seemed interested in pushing properties as the next best thing to white bread.
  156. Which is another reason why RAD is bad. It leads some managers to think
  157. "Hey we don't have to hire those crazy bearded C/C++ programmers who do such
  158. nasty things as insisting on realistic scheduals. Instead we can hire
  159. those liberal arts major and teach them VB. Just like the good old days with 
  160. COBOL."
  161. --------------------------------------
  162. Thaddeus L. Olczyk
  163.  
  164.  
  165.